Add render_blockers to changelog config#2426
Conversation
|
Related to #2350 (comment)
I've add an "Impetus" section to this PR description. If it's insufficient, lmk!
Agreed, though IMO we'll still need somewhere like this config file where we can define which "areas" are relevant to each product (so that we can continue to filter out the valid changelogs that we don't actually want to expose in certain cases).
IMO it's related to supporting independent decision-making. A developer may (rightly) think that a PR is applicable to x and y contexts (and therefore create a changelog that references both products). The related PR might be (automatically) included in a & b releases (e.g. stack and serverless). But we already have use cases where even if a change is applicable and delivered in a specific context (e.g. serverless) we don't want it release-noted, so we need a way to implement those rules at the publishing stage. |
This PR augments the
docs-builder changelog renderfunctionality implemented in #2341It relates to
add_blockersfunctionality in #2350Impetus
The need for this functionality arose when I was working on testing the workflow in elasticsearch and elasticsearch-serverless repos (see draft config files in elastic/elasticsearch#140141 and https://github.com/elastic/elasticsearch-serverless/pull/5156). In the case of the elasticsearch repo in particular, there will be changelogs created for PRs that technically apply to and are delivered in both stack and serverless releases (and thus reasonably end up in the bundles if we're generating them based on the official list of PRs in a release or even if we're generating the bundles based on the "products" info in the changelogs). However, the Elasticsearch stakeholders have provided a list of "areas" that should not be included in the serverless release docs (since they're not something users need to care about e.g. ILM, Watcher, monitoring, etc). Right now we're filtering those out via a spreadsheet that keys off the PR labels so we need to be able to continue to do something along that line with this tooling.
After I got the "areas" filtering working, I realized we ought to do the same for "types" since we've added some types (e.g. docs) that we don't have anywhere to publish yet but that would be nice to start collecting changelogs for nonetheless.
NOTE: For now I've commented the changelogs out instead of removing them entirely, so that we can double-check with PMs or stakeholders until we're absolutely confident in the exclusions. In the long term if we want to remove instead of comment, that's fine with me.
Summary
render_blockersfeature to the changelog configuration system to optionally comment out certain changelog entries from the markdown outputAn entry is blocked if:
render_blockersANDNOTE: The products in the
render_blockersdefinition are intentionally matched against the bundle'sproductsrather than against the individual changelogs'products.Examples
Check out the PR and generate the binaries per README.md:
./build.sh clean ./build.sh publishbinaries cd .artifacts/publish/docs-builder/releaseCreate some changelogs with various types and areas, for example:
Create changelog bundles:
Add a changelog configuration file with a
render_blockerssection. For example, create achangelog.ymlfile that contains:Render the serverless bundle and check whether the
render_blockersare heeded.This command returns the following warning messages:
Render the Elasticsearch bundle but add some feature filtering too:
This command generates the following warnings:
Changes made
ChangelogConfiguration.cs)RenderBlockersproperty toChangelogConfigurationasDictionary<string, RenderBlockersEntry>RenderBlockersEntrywith Areas and Types propertieschangelog.yml.example)render_blockerssection with commented examples for products and areasChangelogService.cs)LoadChangelogConfigurationto:available_types,available_subtypes, andavailable_lifecyclesif not specifiedrender_blockerstypes againstavailable_typesRenderChangelogsrender_blockersChangelogData entry, string repo, HashSet<string> bundleProductIds)ShouldBlockEntryto acceptHashSet<string> bundleProductIdsand check those instead ofentry.ProductsentryToBundleProductsto track which bundle products belong to each entryentryToBundleProductsmappingdocs/changelog.yml)ChangelogCommand.cs:Rendermethod signature--configparameterChangelogRenderInputChangelogRenderInput.cs:Configproperty to store the configuration file pathChangelogServiceTests.cs)RenderChangelogs_WithRenderBlockers_CommentsOutMatchingEntries- Tests basic blocking with single productRenderChangelogs_WithRenderBlockers_CommaSeparatedProducts_CommentsOutMatchingEntries- Tests comma-separated product keysRenderChangelogs_WithRenderBlockers_MultipleProductsInEntry_ChecksAllProducts- Tests entries with multiple productsRenderChangelogs_WithRenderBlockers_UsesBundleProductsNotEntryProductsto verify that bundle products are used, not entry productsRenderChangelogs_WithCustomConfigPath_UsesSpecifiedConfigFile- Tests a config file in a custom location (not in `docs/ subdirectory)available_types,available_subtypes, andavailable_lifecyclesrender_blockersLoadChangelogConfigurationinternal:InternalsVisibleToattribute to allow test accessdocs/contribute/changelog.mdwith the render--configoption and a new "Render blockers" section explaining the formatdocs/cli/release/changelog-render.mdwith the new option, and a short blurb and linkThe implementation follows the same pattern [for commenting out changelog entries] as
hideFeaturesbut checks products, areas, and types from the configuration instead of feature IDs from command-line arguments. When a changelog entry matches any values inrender_blockers, it is commented out in the markdown output and a warning is emitted explaining why.All tests pass and the build succeeds. The feature now supports blocking changelog entries by both areas and types, with proper validation and default handling.
Generative AI disclosure
Tool(s) and model(s) used: composer-1 agent